AWS Lambda, Amazon API Gatewayを使ってサーバーレスアプリをセキュアに構築するワークショップに参加してきた #AWSreInvent

AWS Lambda, Amazon API Gatewayを使ってサーバーレスアプリをセキュアに構築するワークショップに参加してきた #AWSreInvent

今回re:invent2024に参加して、サーバーレスアプリをセキュアに構築するというワークショップに参加してきましたので、こちらの内容をまとめていきたいと思います。
Clock Icon2024.12.03

はじめに

おのやんです。

今回re:invent2024に参加して、サーバーレスアプリをセキュアに構築するというワークショップに参加してきましたので、こちらの内容をまとめていきたいと思います。

セッション概要

SVS307-R | Building secure serverless applications [REPEAT]

In this hands-on workshop, learn techniques to secure a serverless application built with AWS Lambda, Amazon API Gateway, and Amazon Aurora. Discover AWS services and features that you can use to improve the security of a serverless application in five domains: identity and access management, infrastructure, data, code, and logging and monitoring. Finally, explore new features including integrations with Amazon Inspector and Amazon GuardDuty. You must bring your laptop to participate.

SVS307-R|セキュアなサーバーレスアプリケーションの構築 [リピート]

このハンズオンワークショップでは、AWS Lambda、Amazon API Gateway、Amazon Auroraで構築されたサーバーレスアプリケーションをセキュアにするテクニックを学びます。 ID とアクセス管理、インフラストラクチャ、データ、コード、ロギングとモニタリングの 5 つの領域で、サーバーレスアプリケーションのセキュリティを向上させるために使用できる AWS のサービスと機能を発見してください。 最後に、Amazon InspectorやAmazon GuardDutyとの統合を含む新機能を探ります。 参加にはノートパソコンが必要です。

実際の会場の案内がこちらになります。Venetianの3回、Lido3006という会場にて行われました。

IMG_7603 (1)

こちらが、会場内で投影された実際のスライドの表紙です。

IMG_7604 (1)

セッション内容

今回は、合計12個ものセクションからなる3時間の大きめのワークショップとなっていました。最初に認証情報を構築して、アプリケーション部分、データ部分、インフラ部分、ログ・モニタリング部分に大別されており、これらの中でmodule2~12は、順番に左右されず好きな部分から進めてOKという設計でした。逆に、module 0とmodue 1は順番に実施することが必須という扱いでした。

IMG_7607 (1)

最初にお詫びなのですが、今回のワークショップは12セクションのうちの2セクションしか完了できませんでした。ワークショップ冒頭の挨拶で「申し訳ありませんが、このワークショップは全ては終わり切りません」と言い切っていましたし、同席していた外国人の方も1セクションしか進んでいないとぼやいていましたので、最初から興味のある分野のセクションに取り組む前提であるように思われました。セッションページ・ワークショップ用アカウントは3時間ほどで失効になるとのことでしたので、頑張ってセクション2まで終わらせました。

ですので、今回は私が取り組んだ2セクションについて、個人的な感想も踏まえて紹介していきたいと思います。

Amazon API GatewayにAmazon Cognito認証を追加

最初に取り組んだのは、Amazon API Gateway(以下、API Gateway)にAmazon Cognito(以下、Cognito)認証を追加するというものでした。もともとAPI Gateway, AWS Lambda(以下、Lambda), Amazon Aurora(以下、Aurora)の構成要素で、AWS CloudFormation(以下、CFn)テンプレートにてAPIが実装されていました。このテンプレートに適宜リソースを追加する形で、Cognito認証を実装していきました。

10-high-level-architecture-w-auth

LambdaのリソースベースポリシーをAWS IAM Access Analyzer経由で追加

2つ目のセクションでは、AWS IAM Access Analyzer(以下、IAM Access Analyzer)を使ってLambdaのリソースベースポリシーを追加していきました。もともとAdminAccess権限があったIAMロールを、IAM Access Analuzerを通して権限制御することで、AWSベストプラクティスの最小権限にしようという内容です。

スクリーンショット 2024-12-03 12.01.33

ワークショップを通して

今回のワークショップでは、Cognitoの具体的な実装方法について触れることができました。ワークショップのドキュメントに書いてあるコードやコマンドを適宜適用していく流れでしたので、内容を反芻する余裕は今回はあまりありませんでしたが、誰でも叩けるAPIが、Congnito認証を通じてのみ実行可能となるよう実装できたのが良かったです。

IAM Access Analyserのセクションは、実際のユースケースに触れられたという意味では非常に学びになりました。稼働しているAWSリソースのアクセスパターンを分析して最小権限に絞るIAM Access Analyserの動きは、権限を絞るというAWSの大前提に深く根付いた内容だったように感じます。

一方で、普段はある程度APIの実行を予測してこちらで決め打ちしてIAMポリシーを設定するのもあり、実運用を考えるともうひと工夫いるのかな?とも思いました。特にIAMリソースはIaCで管理することも多いため、コンソール上で動的にIAMポリシーを変更する運用は、実運用と比べるともうひとこえ!という印象です。それでも、IAM Access Analyserをワークショップで触ることができたのは非常に良かったです。

今回

同じテーブルで一緒にワークショップを受けた日本人の方に、ほぼ同じ内容のGitHubがあるよと教えていただいたので、最後にこちらを共有したいと思います(当日使われたドキュメントと全く同じわけではないの、で参考程度の情報です)。

筆者も、こちらのブログをもとに復習したいと思います。また当日取り組めなかったセクション内容も、こちらのドキュメントで確認しようとおもいます。では!

https://github.com/aws-samples/aws-serverless-security-workshop?tab=readme-ov-file

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.